Financial management and planning are important to successful operation of business enterprises. In past approaches, financial management and planning mechanisms have been unsatisfactory. For example, in some past approaches current business conditions are not accurately reflected in a financial plan on an ongoing basis. Changes in spending goals and expense targets have been communicated from departments to management with delays that hamper effective planning. Budgets have been submitted in multiple inconsistent formats and without input from all involved managers. Combining budget values from subordinate departments into consolidated budget values for higher-level departments (“roll-up”) has been tedious and required manual action. As a result, enterprises using these approaches have had difficulty carrying out accurate earnings predictions and allocating resources.
In one past approach, financial planning has been performed using spreadsheets and similar computer tools. Typically, each department manager or business unit prepares an independent spreadsheet, based upon individual estimates and formulas. Sharing such data within an organization might be accomplished by attaching files to e-mail communications. As a result, higher-level managers may receive numerous submissions from lower-level individuals that are presented in inconsistent formats, so that the consolidation of such data is cumbersome and time-consuming. Re-allocating resources to accomplish changes in a business plan or to respond to changes in conditions has been carried out manually, which is laborious and slow. These problems are acute in large businesses that are highly de-centralized.
A particular problem in this context involves allocation of spending values. In certain enterprises, one department is viewed as an internal supplier or source of services or resources to other departments that are consumers or recipients. For example, the Facilities department, which is responsible for maintaining offices, laboratories, equipment, and other facilities used by other departments, provides internal maintenance services and related resources to those other departments. Thus the Facilities department is a source and the other departments are recipients.
Normally such a department does not generate revenue, but consumes corporate resources and therefore affects expense levels and the bottom line. The consumption of corporate resources by such a department is often directly related to the volume or rate of its services that are consumed by recipient departments. Accordingly, there is a management need to allocate the aggregate spending of the source department among all its recipient departments. This enables management to understand the total cost of business of recipient departments, improving management. In addition, management of recipient departments desires to view the total costs of their departments, including internally consumed resources. Thus, there is need for a way to allocate a portion of a budget of a source department to the budgets or costs of each recipient department.
However, in past approaches, carrying out such allocations has required relatively rigid manual processes. Typically the allocations are carried out in an ad-hoc manner without use of formal models for amounts of allocation. Management, however, desires to apply allocation computation according to any of numerous allocation models, e.g., based on headcount, square footage occupied by the recipient departments, revenue generated by the recipient departments, etc. Even if such allocation models could be used in prior approaches, there has been no convenient method to rapidly select a different allocation model and re-compute resulting allocation values. There has been no intuitive method of passing allocation values from source plans to recipient plans.
Still another problem of past approaches involves time delay. Since an allocated spending value is one component of the budget of a recipient department, that recipient department normally cannot finalize its budget for itself or for upper-level management review until it receives the allocated spending value from the source department. In past approaches, this has led to delay in preparing and distributing departmental budgets or plans, and the source department can become a bottleneck that can impede the ability of numerous recipient departments from completing their budgets or plans.
Yet another problem relates to budget control. A recipient department manager may find that department spending generally is within budget, but goes over-budget because a source department has over-spent, and therefore the portion of that source department's spending that is allocated to the recipient department is greater than expected. Thus, a budget overage can occur in a way that is beyond the control of the recipient department manager. There is a need for a way for the recipient department to identify allocations in its plan so that such control issues are apparent upon management review of the plan.
Still another problem of past approaches is that the allocation model is maintained outside the planning environment, in a side document or spreadsheet that is used for reference but not fully integrated into the plan. As a result, computing allocations and distributing them to affected departments is cumbersome. There is a need for a way to provide allocation values and an underlying allocation model that are tightly integrated into the planning environment, rather than residing outside it.
Based on the foregoing, there is a clear need for an automated method of allocating spending values associated with a source department among recipient departments that consume services provided by the source department, while holding recipient departments accountable for those expenses that they directly control.
There is a particular need for an automated method of allocating such spending values according to any of a plurality of complex allocation models, such as allocation models based on square footage occupied by recipient departments, revenue generated by the recipient departments, etc.
Another problem associated with existing financial planning systems is that they generally restrict the user's ability to define accounts for planning purposes. A typical financial planning system includes a general ledger or an equivalent that comprises plan or actual revenue and expense values for a plurality of accounts. Each account may have one or more sub-accounts. For example, there may be a Travel Expense account that has sub-accounts for Lodging, Air Travel, and Meals. As another example, the plan may have a Marketing budget included in it, but the user is accustomed to thinking about the portion of the budget that the user wishes to spend on various customers or projects. However, many users prefer to prepare a budget by thinking in terms of how dollars will be spent rather than focusing on accounts; yet in past approaches, the user is given no way to add more detailed line items that are logically located below the sub-accounts and that may have personal meaning or temporary usefulness. If a user is planning a trip for a particular conference, for example, there is generally no way for the user to add a temporary or personal line item to the Travel Expense account or to the Lodging sub-account for expenses relating to that conference or event.
Thus, there is a need for a way to facilitate adding personal or temporary line items to a computer-based financial plan.
There is also a need for a way, when such a line item is later deleted, to manage values associated with past expenses in that line item in a way that is intuitive and that preserves the integrity of values that have been entered in the past.
The rigidity imposed by general ledger accounts also affects planning that focuses on cross-functional programs, rather than individual projects. For example, in past approaches, there is no way in an electronic spending plan to associate spending values with programs that involve multiple different functions of an enterprise. As a specific example, in a given enterprise the Finance, Sales, Marketing, and Engineering departments all may be involved, in different ways, in an initiative involving the launch of a new product. Thus the product launch, which is an example of a program, involves cross-functional activities.
Based on the foregoing, there is a need for a way to provide a spending plan with program values that identify such programs, while also capturing the expenses in the appropriate accounts, such as Travel, etc.
There is a particular need for a way for spending values associated with numerous disparate departments to be associated with a particular program in a manner that facilitates providing consolidated cross-functional reporting of spending and budgets.
A common operation in use of a financial management application is to roll up numbers. In this context, to roll up numbers means to consolidate values from lower level nodes of a hierarchy into higher-level nodes of a hierarchy, or to make information from a subordinate in an organization visible for judgment by his or her superior. Such roll-ups enable a user to view spending values by account, by department, by program, etc. However, a key constraint of past approaches has been that only one organizational hierarchy may be defined. Typically the hierarchy represents departments and business units in one particular way that is analogous to an organization chart of an enterprise. However, this is an undesirable limitation. A particular enterprise may have one hierarchical view of its departments that is based on location in association with function, and an alternate view that is based only on function, or based only on a higher level of authority, such as management only.
Thus, there is a need for a way to enable a spending plan to roll-up values according to more than one hierarchy.